Conventional static application security testing (SAST) is a way for determining whether software is vulnerable to an attack from malicious users. In operation, SAST is a static analysis where the software is examined in a non-executing static state. The software code itself and any accompanying configuration files used at a runtime operation are examined in a variety of ways to predict whether the code has weaknesses that could be exploited by an attacker resulting in a vulnerability.
The techniques for making such predictions vary, but most commercial SAST tools use ‘model checking’, theorem proving, abstract interpretation, and other techniques that require tradeoffs in the precision of such tests in order to arrive at practical results within a reasonable time while considering space constraints on modern computing machinery.
The tradeoffs in precision and the complexity and size of modern applications (i.e., millions to tens of millions of lines of code), means that end users are usually presented with a very large set of weaknesses by the tools which render the analysis useless. To quickly arrive at an overall sense of the weakness of an application and to determine where to focus remediation efforts is a continued challenge when the list of weaknesses (also called ‘findings’) number in the thousands or more, commonly, tens or hundreds of thousands. For a result that takes hours to produce, the result can then take several ‘person’ days or weeks to determine what needs to be fixed and how much effort would be involved. Most weaknesses are presented as individual paths through an application illustrating how attack data promulgates through the code until it reaches its target. Although, many of these weaknesses are related by sharing portions of the path through the code, the individual listing makes it difficult to discern relationships between the weaknesses and obtain a clear understanding where the application needs the most attention.